Subject: comments on comments to DLUR draft

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Fri, 16 Jul 93 09:31:21 EDT

>>> Date: Mon, 5 Jul 93 12:12:27 MET
>>> From: kem <[email-masked]>

>>> Some comments to the APPN DLUR Architecture draft document.

>>> 1. The used terminology should be consistent throughout the document;
>>>    the use of CP-SVR muddles up with CPSVCMGR.
>>>    The term CP-SVR and CPSVRMGR are used with both
>>>    extentions 'pipe' and 'session'. I recommend the following usage
>>>    of this terminology:
>>>    The term CP-SVR-pipe should be used to refer to the sessions
>>>    between DLUS and DLUR for carrying SSCP-PU and SSCP-LU messages
>>>    in general. Thus, this term comprises both sessions between DLUS
>>>    and DLUR.  To refer to just one of these sessions the term
>>>    CPSVRMGR-session should be used. In order to refer to a specific
>>>    of these sessions, CPSVRMGR-conwinner or CPSVRMGR-conlooser
>>>    should be used.

Over the years (yes, years) I've gotten used to thinking of CP-SVR and
CPSVRMGR synonymously - same with session and pipe.  The definition in
Appendix A of CP-SVR pipe matches your recommendation.  As I'm making
changes, I will try to clean up inconsistent terminology, but I cannot
at this point commit to a document-wide editorial sweep.  I believe that
already wherever a specific CPSVRMGR session is discussed, it is already
identified as conwinner or conloser (please let me know if there cases
to the contrary).  Where I will focus is on more consistent use of
CP-SVR pipe as the term for the pair of CPSVRMGR sessions between a DLUR
and a DLUS.

>>> 2. Page 5-5, chapter 5.5.2
>>>    The first sentence uses the new term association instead of
>>>    session.  Are there any reasons for that?

I don't see any reason in particular - I'll change association to
session.

>>> 3. In chapter 5.3.2 (Dynamic DLUS Node Determination) this enhancement
>>>    of the DLUR architecture is announced.  What about the other
>>>    way round: Dynamic DLUR Node Determination?

I'll add a section similar to 5.3.2 in section 5.4 to discuss dynamic
DLUR node determination.  I'm not sure it's as useful to have a function
to dynamically search for DLURs.  When a DLUR needs SSCP services, it
may not be important which DLUS is uses and can therefore use a dynamic
search function.  However, a DLUS will only activate a pipe when it has
an ACTPU to deliver to a particular PU attached to a particular DLUR;
there is no mechanism to search the network for a dependent PU to learn
the PU's DLUR.  Maybe dynamic DLUR would help in backup SSCP and/or CMC
configurations where the DLUS normally activates the pipes.

>>> 4. In chapter 6.1.2 (Internal PU Identification) you differentiate
>>>    between local and downstream PUs. It doesn't matter for the
>>>    architecture 	whether the Node Type 2.0 is local or downstream,
>>>    cause IDBLK/IDNUM has to be carried in the GDS X'1500' anyway.
>>>    It's a matter of a specific product and not one of the
>>>    architecture.

It was an architecture issue until last week.  Earlier this year
IDBLK/IDNUM was agreed on for internal as well as external PUs (if you
look at the REQACTPU format in section D.1.2, in the definitions of
Formats 0 and 1 you'll see different information on where to find PU
identification - I will remove those old, incorrect parenthetical
comments).

Furthermore, the current draft shows PU identification information
included in the XID CV for external PUs for REQACTPU and in the PU TG CV
for internal PUs.  VTAM asked for a consistent interface and so I will
add XID CV for internal PUs in the REQACTPU.

Once that change is made, I believe your comment will be addressed.

>>> 5. Last but not least, the final architecture document should
>>>    describe the architecture using FSM's and not just flow
>>>    diagramms.

I can't sign up for that effort - FSMs are not currently required for
final architecture documentation as it appears in the SNA APPN
Architecture Reference.  If SIG members wish to submit DLUR FSMs, we
(the SIG) could review them and consider them for inclusion in the
document.

>>> 6. On page 5-2 at the end of 2nd paragraph there is a reference to
>>>    byte 8 bit 8 of XID3. The correct spelling should be 'byte 8-9
>>>    bit 8', that's the way SNA-Formats descibes it.

You are correct - I will fix it.

>>> Regards
>>> Willi Kemmerling

Thanks, Willi, for your comments.

Ed Tremblay